「UNIXという考え方」から連想されるすべてのアイデア

ちゃだいん（@chazuke4649）です。

今社内で改めて名著であるとしてその名前をよく見聞きする「Unixという考え方」。積ん読になっていたので最近ようやく読みました。すると驚くほど気づきが多かったので今回ブログで書いてみることにしました。

前提として日頃考えていること

ちょっと自論ですが、IT（情報技術）、コンピューター、インターネット、これらの分野の本質は「課題解決」であると考えます。それを実現するための道具（手段）として現在私たちがありがたく使っている様々な技術が存在すると思うのです。それはどういうことかというと、これらの技術が発達した背景にはいつも何かの課題があり、それを解決するための工程や軌跡がこれらの歴史を作ってきたという風にみて取れるからです。例えば、ワールドワイドウェブの誕生は多くの場面で語り尽くされていますが学会の論文にて引用している文献をいちいちメールや郵送でやり取りするのは大変という課題があり、それを解決するために各論文同士をネットワーク経由でリンクさせる技術として誕生したと言われています。

ただ、「この世に誕生している商品やサービス全ては何か課題を解決するためなんちゃうんかい」と言われると返す言葉もないのですが、今回のIT分野に関してはそれがより顕著に出ていると感じるのです。

その次に何が言いたいかというと、これらIT分野で生み出されたアイデアやデザインパターン、ロジックや仕組みなどは背景として課題解決するためという特徴が強いので、きっと他の分野でも応用できる余地があり、場合によってはイノベーションを起こすヒントになりうると思うのです。

例えば、クラウドコンピューティングは私個人の所感としては、まさに現在の合理性の最適解であると考えます。とにかくシステムをできるだけ合理的に効率よく扱おうと考えたときに現在ではまず最初に検討する対象になるのではないでしょうか。

このような思考を持っている私からすると、「UNIXという考え方」はまさにこれら分野の中で殿堂入りを果たした高濃度のエッセンスであると思えてきます。

さて、せっかくなのでこの本を読み進める中で感じたことを独断と偏見に満ちた見方でまとめてみたいと思います。お目汚しですが何か共感する部分があったり、何かのヒントにでもなれば言うことなしです。

Small is beautiful & Do one thing well

• Small is beautiful
• Make each program do one thing well

なんと言ってもUNIXの定理として最も強力なのは、Small is Beautifulでしょう。さらにそれを具体化したアイデアが"Make each program do one thing well"と捉えています。

Small is beautiful

UNIXの定理の中で最もコアなものがこれのようです。以下にわかりやすくまとまっています。

プログラムを書くときは小さなものから始めて、それを小さなままに保っておく。簡単なフィルタプログラムでも、グラフィックスパッケージでも、巨大なデータベースを構築するするときでも、同じく小さな実用的なプログラムにする。一つの巨大なプログラムにしようとする誘惑に負けないで、シンプルさを追求する。（同書より引用）

この定理は他の定理に幅広く通じるものなので常に念頭に置いていきたいところです。

Make each program do one thing well

和訳で「一つのプログラムには一つのことをうまくやらせる」と書かれています。

最良のプログラムとは、（中略）生涯において一つのことをうまくやるプログラムだ。プログラムはメモリにロードされ、所定の動きをし、次の単一機能のプログラムの実行のために道を譲る。（同書より引用）

また、定理１と定理２の関係性については以下のように説明されています。

一つのことをうまくやるようにアプリケーションを描けば、それは必然的に小さなプログラムになる。その意味で、定理１と定理２は、互いに補い合う関係といえる。小さなプログラムは単一機能になる傾向があり、単一機能のプログラムは小さくなる傾向がある。（同書より引用）

また、以下の記述がまさに今回のようなアイデアの応用につながると感じました。

このアプローチには隠れたメリットがある。現在の仕事に集中することによって、やろうとしていることの本質をつかめるのだ。一つのことをうまくやるようにプログラムが作れないのであれば、おそらく問題のまだ完全には理解していないのだろう。（同書より引用）

これらから以下の物事が連想されました。

ワンメッセージ

広告のコピーライティングの原理原則としてよく耳にする言葉で、要は「１つのキャッチコピーで伝えられるのは、１つのメッセージだけ」ということです。これはどういうことかというと、例えばある定食屋の広告で「安いのにめっちゃ美味くて、メニューが豊富で、店主が美人！」と書いてあったら、ちょっと情報量が多くて混乱する気がしませんか？この場合言いたいことが３つもあるので結局何が１番言いたいことなのかわからない状態です。これを「店主がとても美人な定食屋です」に変更すると（いいか悪いか別として）「とにかく店主が美人な定食屋なのか、すごい自信やな」と、言いたいことは伝わる訳です。

このワンメッセージの原則は、「１つのプログラムには１つのことをうまくやらせる」に通じるものがあります。欲張って２匹のウサギを追って１匹も得られないように、１つのコピーにあれもこれも詰め込むと、結果的に残念ながら何も伝わらない文章になってしまうよ、ということです。何事も極力シンプルな状態を保つことを心がけたいですね。

Less is more

有名な言葉で「より少ないことは、より豊かなことだ」という意味の言葉です。
近代建築家が提唱し始めた言葉だということはWikipediaを見て初めて知りました。
　　 参考）ルートヴィヒ・ミース・ファン・デル・ローエ - Wikipedia

シングルタスク

人間の作業方法としてのシングルタスクです。いわゆる「タスクが複数ある場合、１個に集中して１個ずつ消化していく方が、複数を同時並行でこなすこと（マルチタスク）より生産性が高い」というやつです。これには決定的な引用元があるわけではなく、ビジネス書などにそれとなく書かれていたことが、経験値と照らし合わせたときに自分にはその方が合うと思ったことです。
これに関連して以前社内チャットで「なぜマルチタスクだと生産性が落ちるのか」について「コンテキストスイッチ」という言葉が話題になり、なるほどと思ったので気になる方は以下をどうぞ。
コンテキストスイッチに立ち向かう - 複数案件を抱える中で生産性を高めるために - bussorenre Laboratory

もっとも変化できる者が生き残る

「最も強い者が生き残るのではなく、最も賢い者が生き延びるのでもない。唯一生き残ることが出来るのは、変化できる者である。」

The evolution of a misquotation

【訂正】この言葉はダーウィンではなく、経営学教授のメギンソンの独自解釈によるものでした。ご指摘いただきありがとうございました。参考記事：「ダーウィンの進化論」に関して流布する⾔説についての声明

超有名な言葉ですね。さて、これとUnixの定理にどう関係があるのでしょうか。

定理１と２のメリットとして本書には以下が挙げられています。

• 小さなプログラムは分かりやすい
• 小さなプログラムは保守しやすい
• 小さなプログラムはシステムリソースに優しい

これらはつまり「トラブルや障害、災害、人害に強い」と言い換えることができるかもしれません。さらに言い換えると「変化に強い」わけです。つまり「環境に応じて変化できる生物が最も絶滅せずに生き残こる」わけです。ちなみにこの変化に強いものが生き残るという点は定理４の移植性にも通じる部分があります。

マイクロサービスアーキテクチャ

まさに現在モダンなアプリケーションの設計としてよく耳にするこの概念は、定理１と定理２を応用したといえるレベルでの相関性を感じられます。シンプルで、1つのことをうまくやる個体の集合は、変化に強く、生き残ることができる。

引用元Simple Microservices Architecture on AWS - Microservices on AWS

Build a prototype ASAP

「できるだけ早く試作を作成する」

試作以前のアイデアは。これはこう動くはずだという憶測の域を出ない。この時点では、設計構想はほとんど理解されておらず、おそらく人によって解釈が異なっているだろう。プロジェクトの前進には。全員の合意が必要だ。試作は、具体的に目標を示すことで全員の合意を醸成する。（同書より引用）

このプロトタイピングを絶賛する考え方は、きっと他でもみたことがあるはずです。

例えば、

大切なことは、「何を作るか」を十分に考えた後でプロトタイプを作るのではなく、「何を作ったら良いかよく分からない」段階でプロトタイプを作り始めることである。プロトタイプを作るというプロセスそのものを利用して、自分の頭の中に漠然と存在していたアイデアを目に見えるものにまとめ上げる作業を行うのである。

引用元Life is beautiful: プロトタイプ作りの効用

伝説のプログラマー、中島聡氏もこのように。彼は著書「あなたの仕事はなぜ終わらないのか。」の中でも、プロトタイピングの重要性を執拗なまでに繰り返している。

他には、

ライフデザインにおけるプロトタイピングとは、的確な疑問を掲げ、わたしたちの隠れた偏見や思い込みを排除し、すばやく実験をくり返し、わたしたちが試みたいと思っている道へと進む勢いを生み出すことなのだ。

引用元 LIFE DESIGN(ライフデザイン)――スタンフォード式 最高の人生設計

と、人生設計（ライフデザイン）という分野の中でも、プロトタイピングの恩恵はたっぷりと語られている。

そんな概念に触れる中で連想されたのは次のようなことだ。

スモールスタート

多くのビジネスパーソンが使用する言葉ではないだろうか。これはまさに、small is beautiful と prototyping を掛け合わせたような言葉だと感じる。プロトタイプである以上小さく簡単なものあることはある種必然ともいえるが、確かにスモールスタートを実践することで、仕事を予定より早く終わらせることができたり、構想段階では全く気づかなかった課題にぶち当たることもある。これらは全てプロトタイピングの力なんだと思えてくる。　　

クラウドコンピューティングのベストプラクティス

ちなみに、クラウドコンピューティングの最大のメリットの1つとしても、スモールスタート、小さく始められることは知られている。「百聞は一見に如かず」を地でいく理論ともいえる。

そう、このプロトタイピングの本質は「早く多く実験し、そこから学ぶこと」。まさにPDCAサイクルぐるぐる回転状態。失敗は成功のもとでしかない。昔、知人に女性をナンパすることに長けている人がいて、そんな彼に「どうして君はそんなにモテるんだ。頼む、秘訣を教えてくれ。」とせがんだところ、「失敗の、桁が違うだけやで。」と軽くいなされたことを思い出した。とにかく段階や状況によって、質よりも量が大事な場面が往々にしてある。

アジャイル開発

モックを作ってレビューし、改善していくプロセス。そうアジャイル開発もまさにプロトタイピングの威力を活用した主力の開発手法なんだとも思う。

「許可を得るな、謝罪せよ。」 aka 謝罪ファースト

最後に連想されたのは、弊社クラスメソッドのカルチャーとして知られるこの言葉で、これもプロトタイピングの流れを汲む概念といえる。

この言葉が意味するのは「アクションするのにいちいち許可を得る必要はない。許可を取る時間が無駄。やっていいですかじゃなくてやりましたと言えばいい。その結果間違っていれば謝れば良いだけ」です。

引用元「許可を得るな、謝罪せよ」が意図していること

そばにいると世界が止まって見えるほど疾走感のある人物、すもけ氏が上記個人ブログにてわかりやすく解説しているのでぜひご一読ください。

Choose portability over efficiency

「移植性を最優先する」

前提として、ソフトウェアやプログラムの宿命がある。それは必ずハードウェアの上で動くという運命だ。 ハードウェアが何なのか？性能は？に依存する。ハードウェアなしに存在し得なく、単体ではその価値は発揮されないということだ。

絵本 でいうところのソフトウェアは絵と文字で、ハードウェアは紙を束ねたものであるわけだ。あえて悪くいうとパラサイトである。寄生する対象がないと死んでしまう。そこから考えられること、これまたクラウドコンピューティングはここでも関連づけられる。何せクラウドコンピューティングは最大限にこの移植性を高めた結果であるともいえるわけだ。なぜならクラウドでは、できるかぎりハードウェアの存在を意識しないで済むように全てが設計されている。

• 仮想化・論理単位・コンテナはプロセス単位
• 全てがAPIでインテグレーションされている関係性
• マネージドサービス、FaaS

これらは言い方を変えているだけで結局は「ハードウェアの制約を極力受けずにソフトウェアが機能する状態」を生み出すための様々なアプローチであり、仕組みである。 同じような世渡り上手であるために生き残ったものって他にあるだろうか？

例えば、mp3 がそんなようなものだ。オーディオファイルのデファクトスタンダードともいうべき存在でとても古い規格だ。音質や圧縮率などでみると最適な選択肢とは言えないものの、何せ最も汎用性が高く最も多くのオーディオ機器やプレイヤーで再生可能であるという１点で、その地位を確固たるものとしている。

テコを使え （No More 車輪の再発明）

この定理で言ってることはシンプルだ。すでにあるならそれを利活用せよ。車輪の再発明に時間を割くな。ということだ。

これも物事の筋道としては十分納得ができる。権利云々の話は別として人類レベルの全体最適で考えるならば、なぜせっかく他人がその貴重な人生の時間を費やして見つけた発見という名のバトンを受け継いで次につなげないのだ。という話だ。先人の切り開いた道を歩まず、わざわざ藪の中を掻き分け同じゴールを目指す意味などほとんどないということだ。

独自性やアイデンティティの話で、何かを履き違えてしまい時間をロスするのはもったいない。人のものをパクったからといってあなたの個性や自尊心は決して傷つかないし、むしろありがたく頂戴しその上でオリジナリティを発揮せよということだ。

例えば、ヒップホップという音楽にはサンプリングという文化がある。これは既存の楽曲の一部分を借用（サンプリング）し、新たな楽曲を生み出すことだ。この手法はヒップホップの聡明期の頃から行われてきたが、もちろん著作権的な部分でグレーだったりする場合ああれど、純粋に音楽としてはご存知の通り成功を収めた。

逆に彼らに言わせるとサンプリングは借用元の音楽やその作曲者に対する尊敬の念であり、それが優れているから再利用して新たな価値を生み出すわけだ。

そのような発想の転換が必要なケースはこれからも起こりうるだろう。

終わりに

このように、UNIXという考え方に書かれている数々の定理は、その多くが他分野にも共通する真理めいたアイデアが詰まっている。ここまで付き合ってくれたあなたはきっと私と同じようにこういったことを妄想するのが好きなタイプの人間だろうから、ぜひそのおかずに本書をオススメします。

徒然なるままに書きすぎて、前半と後半で文体がアベコベな、なんともひどい乱文となってしまった。とはいえ、プロトタイプでいいから早く外気に触れさせた方が結果恩恵があるというものなのであえて、このまま解き放ってみることにします。←

それではこの辺で。ちゃだいん（@chazuke4649）でした。